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applicant believes that the claim language in question corresponds to the claimed detetmining 
module that determines whether a reply to the ICMP ping pack came from the DHCP client 
requesting the IP address allocation or from another DHCP client. In the sentence bridging 
pages 2 and 3 of the Office Action, the Office Action states that the specification does describe 
the claimed features, but then asserts that there is no description of how this module carries the 
determination process such that one can make or use the invention. 

Further, the Advisory Action (on page 2) states that there is no description of how the 
features are specifically implemented such that one of ordinary skill in the art could make and/or 
use the claimed features. More specifically, the Advisory Action (on page 2) questions whether a 
reply to a ping may be received from a same client that issues a request for an IP address 
allocation. The Advisory Action (on page 1) also states that the specification offers no 
description or explanation of how the determining module can specifically distinguish between a 
response from a requesting DHCP client and a response for another DHCP client. 

In response to the Office Action and the Advisory Action, one skilled in the art would 
know that a DHCP server would know how to distinguish replies from different clients. That is, 
a DHCP server manages address allocation to clients. Accordingly, when the DHCP server has 
allocated IP addresses to clients, the server knows what address was allocated to each client. 
More specifically, the DHCP server may manage addresses in a MAC address form. The MAC 
addresses are respectively matched with IP addresses allocated to clients. 
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Additionally, a DHCP client may send a DHCP discover message to the server when the 
client requests an IP allocation. At that time, the message may include the DHCP client's 
hardware address (i.e., the MAC address). Consequendy, the DHCP server can distinguish 
between different clients based on MAC addresses, and the DHCP knows the client's IP 
address. The DHCP server may send a ping (i.e., an ICMP echo request) when it receives the 
DHCP discover message from the DHCP client. Therefore, if the DHCP server had sent the 
ping to the DHCP client, the server should have already known the corresponding client's MAC 
address (because the message includes the MAC address). 

The above description is believed to answer the questions raised in the Advisory Action 
and therefore should serve as additional arguments as set forth under 37 C.F.R. §1.114. Thus, 
applicant respectfully submits that one skilled in the art would have been able to make and/ or 
use the claimed determining module based on the present specification and claims. The 
following is more detailed arguments corresponding to those in the response filed April 20. 
Applicant requests the Patent Office to fully consider these arguments in view of the above 
description. 

Applicant respectfully submits that at least FIG. 4 and paragraphs [46]-[49] of the present 
specification correspond to the features relating to the determining module. As stated in the 
response filed April 20, 2006, one skilled in the art would know that Internet Control Message 
Protocol (ICMP) is part of a TCP/IP standard. For example, please see RFC 792 "Internet 
Control Message Protocol (ICMP)." Applicant respectfully submits that based on the well- 
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known ICMP being part of a TCP/IP standard, one skilled in the art would clearly know how to 
make and/or use the claimed determining module as recited in independent claim 1 (as well as 
the features in the other independent claims) based on the present specification. Stated 
differently, one skilled in the art would have known how to make and/ or use a determining 
module that is capable of receiving a reply to an ICMP ping packet and determining features of 
the received message (based on understanding of ICMP messages, for example). 

The Office Action (on at least page 2) questions whether a reply to a ping may be 
received from the same client that issues a request for an IP address allocation. See the above 
description regarding this matter; paragraph [46], last three lines of the specification; and the 
response filed on July 25, 2005 at page 9, lines 4-5. 

Applicant submits that the present specification clearly describes features such as shown 
in FIG. 4. One skilled in the art would have known how to implement this methodology from 
reading the present specification. As one example, one skilled in the art would understand the 
technology of ICMP messages and based on the written description, would have known how to 
make and/or use the claimed features. For at least these reasons, applicant respectfully submits 
that the specification adequately provides an enabling description to one skilled in the art in 
order to make and/or use the features of the independent claims (and the corresponding 
dependent claims). Withdrawal of the rejection is respectfully requested. 
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B. Rejection under 35 U.S.C. §102 

The Office Action rejects claims 1-21 under 35 U.S.C. §102(b) over "Join server technical 
help: Chapter 5 Server/Security Parameter," technical manual from UC Davis Information 
Resources Unix Help website, November 11, 1996 (hereafter JOIN). The rejection is respectfully 
traversed with respect to the pending claims. 

Independent claim 1 recites a determining module that determines whether a reply to the 
ICMP ping packet came from the DHCP client requesting the IP address allocation or from 
another DHCP client. Independent claim 1 also recites a first operation module that conducts a 
DHCP procedure using the registered relevant event information if the reply is from the DHCP 
client requesting the IP address allocation, and that changes the registered relevant event 
information through the ICMP module and issues a new ICMP ping packet if the reply is from 
the another DHCP client. 

JOIN does not teach or suggest at least these features of independent claim 1. More 
specifically, the Office Action and Advisory Action appear to rely on "BOOTP Client Lease 
Extension" (page 6) for features relating to a reply to the ICMP ping packet being received from 
the DHCP packet requesting an IP address allocation. The Office Action and Advisory Action 
also appear to rely on "Ping BOOTP Client" and 'Ting Timeout" (page 8) for features relating 
to a reply to the ICMP ping packet being from another DHCP client. However, these sections 
do not relate to both a reply from the DHCP client and/ or a reply from the another DHCP 
client. JOIN does not distinguish between a DHCP client and another DHCP client and 
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perform different operations based on the different clients. Additionally, the Office Action's 
comments on page 4 do not discuss conducting a DHCP procedure using registered relevant 
event information or changing the registered relevant event information (based on the reply). 

Accordingly, JOIN does not teach or suggest a first operation module that conducts a 
DHCP procedure using the registered relevant event information if the reply is from the DHCP 
client requesting the IP address allocation, and that changes the registered relevant event 
information through the ICMP module and issues a new ICMP ping packet if the reply is from 
the another DHCP client. For at least these reasons, independent claim 1 defines patentable 
subject matter. 

Independent claim 8 recites conducting a DHCP procedure using the registered relevant 
event information and erasing the registered relevant event information from the DHCP ping 
entry when a reply to the ICMP ping packet is received from the DHCP client requesting the IP 
address allocation . Independent claim 8 also recites changing the relevant event information 
registered in the DHCP ping entry and issuing a new ICMP ping packet when a reply to the 
ICMP ping packet is received from another DHCP client . For at least similar reasons as set forth 
above, JOIN does not teach or suggest at least these features of independent claim 8. Thus, 
independent claim 8 defines patentable subject matter. 

Independent claim 14 recites a determining module that determines whether a reply to 
the issued ping packet came from a first client that requested the IP address allocation or from a 
second client other than the first client . Independent claim 14 also recites a first operation 
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module that allocates an IP address to the first client if the first client is determined to have sent 
the reply. For at least similar reasons as set forth above, JOIN does not teach or suggest at least 
these features of independent claim 14. Thus, independent claim 14 defines patentable subject 
matter. 

Independent claim 18 recites determining whether a reply to the issued ping packet came 
from a first client that requested t he IP address allocation or from a second client other than the 
first client. Independent claim 18 also recites allocating the IP address to the first client if the 
first client is determined to have sent the reply. For at least similar reasons as set forth above, 
JOIN does not teach or suggest at least these features of independent claim 18. Thus, 
independent claim 18 defines patentable subject matter. 

For at least the reasons set forth above, each of independent claims 1, 8, 14 and 18 define 
patentable subject matter. Each of the dependent claims depends from one of the independent 
claims and therefore defines patentable subject matter at least for this reason. In addition, the 
dependent claims recite features that further and independendy distinguish over the applied 
references. For example, dependent claim 15 recites that the first operation module discards the 
IP address allocation request if the second client is determined to have sent the reply. See also 
dependent claim 19. For at least similar reasons as set forth above, JOIN does not teach or 
suggest discarding the IP address allocation request if the second client is determined to have 
sent the reply. Accordingly, dependent claims 1 5 and 1 9 define patentable subject matter at least 
for these additional reasons. 
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CONCLUSION 

In view of the foregoing, it is respectfully submitted that the application is in condition 
for allowance. Favorable consideration and prompt allowance of claims 1-21 are earnestly 
solicited. If the Examiner believes that any additional changes would place the application in 
better condition for allowance, the Examiner is invited to contact the undersigned attorney at the 
telephone number listed below. 

To the extent necessary, a petition for an extension of time under 37 C.F.R. 1.136 is 

hereby made. Please charge any shortage in fees due in connection with the filing of this, 

concurrent and future replies, including extension of time fees, to Deposit Account 16-0607 and 

please credit any excess fees to such deposit account. 

Respectfully submitted, 
PLESHNER & KIM, LLP 




David C. Oren 
Registration No. 38,694 

P.O. Box 221200 
Chantilly, Virginia 20153-1200 
703 766-3701 Dco/kah 
Date: June 20, 2006 

Please direct all correspondence to Customer Number 34610 
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